home *** CD-ROM | disk | FTP | other *** search
/ Amiga Format CD 31 / Amiga Format CD31 (1998-09-02)(Future Publishing)(GB)(Track 1 of 2)[!][issue 1998-10].iso / -seriously_amiga- / misc / fblit / programmers_note.doc < prev    next >
Text File  |  1998-07-16  |  3KB  |  56 lines
  1.  
  2. This is just a short ramble for people who think their software might
  3. benefit from FBlit.
  4.  
  5. Taking advantage of fblit is simply a matter of putting data in fast ram
  6. instead of chip. Intuition images can be kept in, and rendered from, fast
  7. mem. Bitmaps can also have planes in fast mem and still be blitted through
  8. the OS into a window. The downside is that you cannot use the OS to render
  9. into a fast ram bitmap. There will be some OS routines you can use on a
  10. fast bitmap(rastport), but any that use the blitter (other than 'BltBitMap'
  11. etc.) will fail.
  12.  
  13. SuperBitMap windows seem to work with fast bitmaps, but again, many gfx.lib
  14. etc. routines will not work...
  15.  
  16. Wether or not FBlit can do anything usefull for you obviously depends on
  17. what your programme is about. It is irrelevent for non-OS software BTW. The
  18. main benefits come when dealing with pre-rendered graphics, or those
  19. generated without the OS(blitter). These can generally be kept/generated in,
  20. and handled through the OS from fast ram, in exactly the same way you would
  21. normally do it in chip mem. The only thing the programme needs to do is to
  22. put the structures in fast ram instead of chip, and the only noticeable
  23. difference should be reduced chip mem use and increased speed.
  24.  
  25. I have been asked for the WBTunnel source as a demonstration, but it really
  26. is such a mess, and the relevent technique is so simple that it is easier
  27. just to describe what it does here. It renders into an intuition image and
  28. then calls 'DrawImage' to put the image in the window. The 'RTG' switch
  29. defines wether the image structure should be allocated in chip or fast
  30. memory. That's all there is. It is in fact 100% OS legal software, at least
  31. while it's intuition image structure is in chip ram.
  32.  
  33. There is only one way a programme can directly interact with fblit, that is
  34. by changing your task name to 'FBLITPLANES'. Any task with that name will
  35. (probably!) get (non-displayable) bitmaps with planes allocated in fast ram
  36. when calling 'AllocBitMap'. There are some dangers in this behaviour eg. if
  37. a task with that name owns a window, the OS may allocate bitmaps in fast
  38. mem when your window is overlapped etc. and cause corruption. I haven't
  39. tried this, but it is likely that the task name must be changed to
  40. 'FBLITPLANES', the allocation done and the name changed back within a
  41. forbid/permit if the task has any OS GUI at the time. This behaviour is
  42. really just a relatively easy/transparent method for getting a bitmap with
  43. planes in fast mem, on condition that fblit is running, or a normal chip
  44. bitmap otherwise. ('FBLITPLANES' is simply a task name that is included in
  45. the 'FAllocBitMap' promotion list by default, the effect of using this task
  46. name is just the same as if a user adds your task name to the list...)
  47.  
  48. So, this whole madcap scheme is basically supposed to allow the use of fast
  49. ram for graphics data in a way that is both very easy and (sort of) OS
  50. legal from the apps point of view. So long as the option exists for the
  51. user to choose to have the graphics back in chip mem, the app ahould be
  52. safe on any past/current/future compatible OS, RTG systems, and standard
  53. (non-RTG) systems that aren't running fblit. Though, obviously, an app
  54. could end up 'unrunable' on some systems if it has more gfx than can fit in
  55. chip mem, or if it relies on speed/non-flicker...
  56.